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Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Conmiittee Smart Card Platform (SCP). 

The contents of the present document are subject to continuing work within TC SCP and may change following formal 
TC SCP approval. If TC SCP modifies the contents of the present document, it will then be republished by ETSI with 
an identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

early working draft; 

1 presented to TC SCP for information; 

2 presented to TC SCP for approval; 

3 or greater indicates TC SCP approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 

The present document defines a communication interface between the UICC and a contactless frontend (CLE) in the 
terminal. This interface allows the card emulation mode independent of the power state of the terminal as well as the 
reader mode when the terminal is battery powered. 

The aim of the present document is to ensure interoperability between a UICC and the CLE in the terminal 
independently of the respective manufacturer, card issuer or operator. Any internal technical realization of either the 
UICC or the CLE is only specified where these are reflected over the interface. 
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1 Scope 

The present document specifies the Single Wire Protocol (SWP). SWF is the interface between the UICC and the CLF. 
The present document defines: 

• Layerl: The physical layer which is responsible for activating, maintaining and deactivating the physical link 
between the UICC and the CLF. It defines electrical (voltage and current levels, timing and coding of voltage 
and current levels), mechanical (physical contacts) and functional (data rates) specifications. It also defines the 
initial communication establishment and the end of the connection. 

• Layer 2: The data link layer which is responsible for the physical addressing of the data through frames and 
Link Protocol Data Units (LPDU). The data link layer is also responsible for error notification, ordered 
delivery of frames and flow control. This layer can be split into two sub-layers: 

The Medium Access Control (MAC) layer which manages frames. 

The Logical Link Control layer which manages LPDUs and is responsible for the error-free exchange of 
data between nodes. Three different Logical Link Control layers are defined in the present document. 

2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• In the case of a reference to a TC SCP document, a non specific reference implicitly refers to the latest version 
of that document in the same Release as the present document. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 
cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI TS 102 221: "Smart Cards; UICC-Terminal interface; Physical and logical characteristics". 

[2] ISO/IEC 14443-2: "Identification cards - Contactless integrated circuit(s) cards - Proximity cards - 

Part 2: Radio frequency power and signal interface". 

[3] ISO/IEC 14443-3: "Identification cards - Contactless integrated circuit(s) cards - Proximity cards - 

Part 3: Initialization and anticollision" . 

[4] ISO/IEC 14443-4: "Identification cards - Contactless integrated circuit(s) cards - Proximity cards - 

Part 4: Transmission protocol". 
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[5] ISO/IEC 13239: "Information technology - Telecommunications and information exchange 

between systems - High-level data link control (HDLC) procedures". 

[6] ETSI TS 102 600: "Smart Cards; UICC-Terminal interface; Characteristics of the USB interface". 

[7] ETSI TS 102 223: "Smart Cards; Card Application Toolkit (CAT)". 

[8] ISO/IEC 18092: "Information technology - Telecommunications and information exchange 

between systems - Near Field Communication - Interface and Protocol (NFCIP-1)". 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

Not applicable. 



3 Definitions, symbols, abbreviations and coding 

conventions 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

card emulation mode: a mode where the UICC emulates a contactless card through the CLE 

class A operating conditions: terminal or a smart card operating at 5 V ± 10 % 

class B operating conditions: terminal or a smart card operating at 3 V ± 10 % 

class C operating conditions: terminal or a smart card operating atl,8V±10% 

contactless frontend: circuitry in the terminal which: 

• handles the analogue part of the contactless communication; 

• handles communication protocol layers of the contactless transmission link; 

• exchanges data with the UICC. 

full duplex: Simultaneous bidirectional data flow 

half duplex: Sequential bidirectional data flow 

idle bit: bit with logical value sent outside a frame 

master: entity which provides the SI signal 

reader mode: mode where the UICC act as a contactless reader through the CLF 

state H: high electrical level of a signal (voltage or current) 

state L: low electrical level of a signal (voltage or current) 

SI: signal from the master to a slave 

S2: signal from the slave to the master 

slave: entity which is connected to the master and provides the S2 signal 
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transition sequence: signal sent by the master during RESUME, consisting of the falling edge, the state L period and 
the rising edge of an idle bit 

TS 102 221 [1] interface: asynchronous serial UICC-Terminal interface defined in TS 102 221 [1], using RST on 
contact C2, CLK on contact C3 and I/O on contact C7 

UICC powering modes: 

• Full power mode: the UICC is powered according to TS 102 221 [1] limitations in operating state. 

• Low power mode: the UICC is running in a reduced power mode as defined in the present specification. 
wakeup sequence: sequence transmitted by the slave before each frame 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

Gnd Ground 

Ifj Current signalling state H of S2 

II Current signalling state L of S2 

T Bit duration 

Tjj^ Duration of the state H for coding a logical 1 of SI 

TfjQ Duration of the state H for coding a logical of S 1 

T(-Lp Processing time of the CLF for a packet of data 

Tj^Pj^ Transfer time of contactless command or response over the RF interface 

"^SWP Transfer time a single SWP packet of date 

"^UICC Processing time of the UICC for a contactless command 

tp Fall time 

tj^ Rise time 

Vcc Supply Voltage 

Vjfj Input Voltage (high) 

VjL Input Voltage (low) 

Vqjj Output Voltage (high) 

Vql Output Voltage (low) 

3.3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ACT ACTivation protocol 

CLF ContactLess Frontend 

CLK CLocK 

CLT ContactLess Tunnelling 

CRC Cyclic Redundancy check 

EOF End Of Frame 

HDLC High level Data Link Control 

I/O Input/Output 

ISO International Organization for Standardization 

LLC Logical Link Control 

LPDU Link Protocol Data Unit 

LSB Least Significant Bit 

MAC Medium Access Control 

MSB Most Significant Bit 

NFCIP-1 Near Field Communication - Interface and Protocol 

PCD Proximity Coupling Device 

PICC Proximity Integrated Circuit Card 

REJ Reject 
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RF 


Radio Frequency 


RFU 


Reserved for Future Use 


RNR 


Receive Not Ready 


RR 


Receive Ready 


RST 


ReSeT 


SREJ 


Selective Reject 


SHDLC 


Simplified High Level Data Link Control 


SOF 


Start Of Frame 


SWIO 


Single Wire protocol Input/Output 


SWP 


Single Wire Protocol 


USB 


Universal Serial Bus 
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3.4 Coding conventions 

For the purposes of the present document, the following coding conventions apply: 

• All lengths are presented in bytes, unless otherwise stated. 

• Each byte is represented by bits b8 to bl, where b8 is the Most Significant Bit (MSB) and bl is the Least 
Significant Bit (LSB). In each representation, the leftmost bit is the MSB. 

• Hexadecimal values are enclosed in single quotes ('xx'). 

In the UICC, all bytes specified as RFU shall be set to '00' and all bits specifies as RFU shall be set to 0. 



Principle of the Single Wire Protocol 



The SWP interface is a bit oriented, point-to-point communication protocol between a UICC and a contactless frontend 
(CLF) as shown in figure 4.1. 



The CLF is the master and the UICC is the slave. 



S1 
CLF to UICC 



SWIO 
OUTPUT 



CLF 
(Master) 



Gnd 



S2 



S1 



SWIO 
INPUT 



UICC 
(Slave) 



Gnd 



S2 
UICC to CLF 

Figure 4.1 : SWP data transmission 

The principle of the Single Wire Protocol is based on the transmission of digital information in full duplex mode: 

• The signal SI is transmitted by a digital modulation (L or H) in the voltage domain. 

• The signal S2 is transmitted by a digital modulation (L or H) in the current domain. 
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When the master sends S 1 as state H then the slave may either draw a current (state H) or not (state L) and thus transmit 
S2. With pulse width modulation bit coding of SI, it is possible to transmit a transmission clock, as well as data in full 
duplex mode. This bit coding of SI is described in clause 8.1 of the present document. S2 is meaningful only when SI 
is in state H. 



System architecture 



5.1 



General overview 



Terminal 



Coupling 
Coil 



Power 

supply 

i 




Vcc 



SWIO 



Gnd 



RST (C2 
CLK (C3] 



C5) 

^C6) 

^CT^ I/O 

'CS"^ D- 



UICC 



Figure 5.1 : CLF-UICC physical link 

Figure 5.1 represents the physical link between the CLF and the UICC. The contact C6 of the UICC is connected to the 
CLF for the transmission of SI and S2. 



5.2 TS 102 221 support 



A UICC supporting the SWP interface and a terminal supporting SWP shall remain compliant with TS 102 221 [1]. 

A terminal supporting the SWP interface utilises contact C6; therefore class A operation cannot be supported. 

For the low power mode, the electrical characteristics of contact CI (Vcc) are extended by the present document. 
Contacts C2, C3 and C7 shall behave as specified in TS 102 221 [1]. 



5.3 Configurations 



The terminal indicates the support of SWP interface in the terminal capability as defined in TS 102 221 [1]. The UICC 
indicates support of SWP interface in the Global Interface bytes of the ATR as defined in TS 102 221 [1]. 

When both the terminal and the UICC are supporting the SWP interface, several operation modes become possible in 
addition to the operation modes already supported by terminal not supporting the SWP interface and the UICC: 

• Only the SWP interface is activated. This may occur while the whole terminal is powered and other interfaces 
(e.g. the TS 102 221 [1] or TS 102 600 [6] interfaces) are not activated, or while the terminal is switched OFF 
(i.e. the whole terminal may not be operative). 
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• The SWP interface is activated while a session on another terminal-UICC interface is in progress (e.g. the 
TS 102 221 [1] or TS 102 600 [6] interface). In this case, the different interfaces shall be active concurrently, 
and therefore actions on the SWP interface shall not disturb the terminal-UICC exchange on the other 
interfaces and vice-versa. 

5.4 Interaction with other interfaces 

Communication between a terminal supporting the SWP interface and a UICC supporting the SWP interface take place 
either over the SWP interface on contact C6 as specified in the present document, or over the interfaces using contacts 
C2, C3, C4, C7 and C8 as defined in TS 102 221 [1] and TS 102 600 [6]. Signalling on a contact assigned to one 
interface shall not affect the state of other contacts assigned to another interface. This also applies to the activation 
sequence of the UICC. The power provided on contacts CI (Vcc) and C5 (Gnd) shall cover the power consumption of 
all active interfaces of the UICC. 

Operation of the SWP interface after activation shall be independent from operation of other interfaces (e.g. the 
TS 102 221 [1] or TS 102 600 [6] interface) that may be implemented on the UICC. 

Any reset signalling (RST signal on contact C2 as specific to the TS 102 221 [1] interface or logical reset on 

TS 102 600 [6] interface) shall only affect the UICC protocol stack related to these interfaces. SWP-related processes 

shall not be affected by another interface reset signal. 

A logical reset signalling on the data link layer (SHDLC RSET) over the SWP interface as well as activation and 
deactivation of SWP interface shall not affect any of the other interfaces. 



6 Physical characteristics 

6.1 Temperature range for card operation 

In the present document, all parameter values for the SWP interface shall apply for the standard temperature range for 
storage and full operation as defined in TS 102 221 [1]. 

6.2 Contacts 

6.2.1 Provision of contacts 

Vcc (contact CI) and Gnd (contact C5) provided in the UICC shall be reused by the terminal to provide power supply. 
SWIG (contact C6) of the UICC shall be used for data exchange between the UICC and the CLF. 

6.2.2 Contact activation and deactivation 

The terminal shall connect, activate and deactivate contacts C2, C3 and C7 of the UICC in accordance with the 
operating procedures specified in TS 102 221 [1] and the contacts C4 and C8 in accordance with the operating 
procedures specified in TS 102 600 [6] when these interfaces are used. The terminal shall activate the contact CI (Vcc) 
according to the TS 102 221 [1]. 

A terminal may decide not to perform the contact and interface activation of SWP if it detected in either this or a 
previous card session that the UICC does not support the SWP. 
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6.2.2.1 SWIO contact activation 

As long as Vcc (contact CI) is not activated, the terminal shall keep SWIO (contact C6) deactivated (SI state L). 

The terminal activates Vcc (contact CI) in order to either activate the SWP interface or Vcc (contact CI) is activated 
due to the activation of another interface on the UICC. 

The activation of the SWIO (contact C6) takes place when the terminal sets the SWIO signal from state L to state H. 
This indicates to the UICC to activate its SWP interface. 

6.2.2.2 SWIO contact deactivation 

In order to deactivate SWIO (contact C6), the terminal shall set SWP to the DEACTIVATED state as defined in 
clause 8.3. 

6.2.2.3 Deactivation of the UICC 

In addition to the deactivation as given in TS 102 221 [1] and TS 102 600 [6] the terminal shall deactivate SWIO 
(contact C6) before deactivating Vcc (contact CI). 

6.2.3 Interface activation 
6.2.3.1 Initial interface activation 

The following process shall take place after the contact activation of SWIO (contact C6). 

This process makes use of SWP interface states management described in clause 8.3 and of the ACT LLC layer as 
described in clause 9.4. 

The sequence is as follows: 

• The UICC shall indicate that it is ready to exchange data via SWP by resuming SWP. 

In case the CLF does not detect an SWP resume by the UICC, the CLF shall assume that the UICC does 
not support the SWP interface and the CLF shall deactivate SWIO (contact C6). 

• The CLF shall put SWP into ACTIVATED state. 

In case the UICC does not detect the SWP ACTIVATED state, the UICC shall set S2 to state L not later 
than T32 INHIBIT ^^^^^ ^^^ UICC has put S2 in state H. The UICC shall not respond to further attempts 
from the CLF to communicate via SWP and shall wait for UICC deactivation or shall retrieve 
information about SWP capability of the terminal via any other UICC interface (see clause 6.2.4). 

• The UICC shall send the first ACT_S YNC frame and wait for the first frame from the CLF. 

• When the CLF has received the first ACT_SYNC frame from the UICC, the CLF shall take the following 
actions: 

If the CLF has received a correct ACT_S YNC frame and the terminal provides full power mode, the 
CLF shall respond with an ACT_POWER_MODE frame with FR bit set to indicating full power mode. 

If the CLF has received a correct ACT_S YNC frame and the terminal provides low power mode the CLF 
shall consider the initial interface activation as being successful and shall not send further ACT frames. 

• When the CLF has received a corrupted frame or no frame the CLF shall request the UICC to repeat the last 
ACT_S YNC frame by sending an ACT_POWER_MODE frame with FR bit set to 1 indicating the current 
terminal power mode. 
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• When the UICC has received an ACT_POWER_MODE frame from the CLF, the UICC shall take the 
following actions: 

If the UICC has received a correct ACT_POWER_MODE and the FR bit of this frame is 1 , then the 
UICC shall repeat the last ACT frame it had sent. If the FR bit is then the UICC shall respond with an 
ACT_READY frame. 

If the UICC has received a corrupted frame, the UICC shall not respond. 

• When the CLF has received an ACT frame in response to an ACT_POWER_MODE frame, the CLF shall take 
the following action: 

the CLF shall consider the initial interface activation as being successful and shall not send further ACT 
frames if it has received: 

an ACT_S YNC frame in response to an ACT_POWER_MODE frame with FR bit set to 1 ; or 

■ an ACT_READY frame in the case that the CLF has previously correctly received the first 
ACT_SYNC frame for the UICC. 

• When the CLF has received a corrupted frame, the CLF shall request the UICC to repeat the last ACT frame 
by sending an ACT_POWER_MODE frame with FR bit set to 1 indicating the current terminal power mode. 

• When the CLF has not received an ACT frame in response to an ACT_POWER_MODE frame, the CLF shall 
take the following actions: 

In this case, the CLF shall request the UICC to repeat the last ACT frame by sending an 
ACT_POWER_MODE frame with FR bit set to 1 indicating the current terminal power mode. 

The CLF shall not send more than three ACT_POWER_MODE frames with the FR bit set to 1 . 

The CLF shall treat a received ACT frame like a corrupted frame when it does not occur in the order defined in the 
sequence above. 

If the interface activation was not successful the CLF shall assume that the UICC does not support SWP interface. In 
this case the CLF shall deactivate SWIO (contact C6). 

All ACT-SYNC frames sent by UICC during initial interface activation shall contain the ACTJNFORMATION field. 

6.2.3.2 Subsequent interface activation 

The initial interface activation sequence shall also be applied after the transition of S 1 to state H from the state 
DEACTIVATED, with the following modifications: 

• The UICC shall not send an ACTJNFORMATION field in any of the ACT frames. 



• 



When the CLF has received the first ACT_SYNC frame from the UICC, the CLF shall take the following 
action: 

If the CLF has received a correct ACT_S YNC frame, the CLF shall immediately consider the subsequent 
interface activation as being successful and shall not send further ACT frames. 
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6.2.3.3 Tinning parameters 

Figure 6.1 shows the timing conditions for the initial interface activation after Vcc (contact CI) activation, for the case 
when an ACT_POWER_MODE frame is sent. Table 6.1 gives the timing values. 



Trf 1st cmdD 




NOTE 1 : The relationship to RF-field appearance is shown for information only. 

NOTE 2: Timing marked (*) are informative. The compliancy to the startup time of the RF application Tpp ^^^ q^^^ 

(for ISO/IEC 14443-3 [3]: 5msec from RF-field 1 .5A/m to be able to receive REQA, REQB) is achieved by 
the CLF by balancing Tpp ^qq, Tg^ ^^qj py^, T^Lpusju and the SWP bit rate properly. The system is 

designed in a way, that the CLF may keep the timing constraints when relying on the 1^* SYNCJD 
transmission. In case this fails it is up to the CLF to request resending SYNCJD and go for the next 
REQA, REQB. 
NOTE 3: The value of Tg^ ^^qj ppp implemented by the CLF should be greater than Tg^ ^^qj ppp + the SWP 

resume time. This is to ensure that an ACT frame from the CLF is not sent when an ACT(response) frame 
from the UICC is sent. 

Figure 6.1 : Initial interface activation on RF-field appearance (example) 
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Table 6.1: Timing parameters for initial interface activation on RF-field appearance 



Symbol 


Parameter 


Minimum 


Maximum 


Unit 


"'"S1_HIGH_V 


SWIO (contact C6) activation time after Vcc 
(contact C1) activation. 


1 000 


- 


\1S 


"'"S2_ACT_RES_V 


UICC resumes SWP for sending 1^^ 
ACT SYNC frame. 





700 


^s 


"'"S2_ACT_FRP 


UICC responds to ACT_POWER_MODE 
frames (calculated from last bit of EOF to 
SWP resume or wakeup sequence). 





2 000 


^s 


"•"82 INHIBIT 


UICC detection timeout (see clause 6.2.3.1) 


- 


100 


ms 



The interface activation from the SWP DEACTIVATED state is given in figure 6.2 for the case when an 
ACT_POWER_MODE frame is sent. Additional timing values are given in table 6.2. 



TRF_1st_CMD(*) 




NOTE 1 : The relationship to RF-field appearance is shown for information only. 

NOTE 2: Timing marked (*) are informative. The compliancy to the startup time of the RF application Tpp ^^^ q^^ 

(for ISO/IEC 14443-3 [3]: 5 ms from RF-field 1 ,5 A/m to be able to receive REQA, REQB) is achieved by 
the CLF by balancing Tg^ |_||q|_| ^, Tg^ j^^j py^, Tq|_p|,sj|j ^ and the SWP bit rate properly. The system is 

designed in a way, that the CLF may keep the timing constraints when relying on the 2"^ SYNCJD 
transmission in case the 1^* transmission fails. 

Figure 6.2: Interface activation from the DEACTIVATED state on RF-field appearance (example) 
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Table 6.2: Additional timing parameters for the interface activation 
from the deactivated state on RF-f ield appearance 



Symbol 


Parameter 


Minimum 


Maximum 


Unit 


"'"S2_ACT_RES_D 


UICC resumes SWP for sending 1^^ 
ACT SYNC frame 





500 


^s 



6.2.3.4 Impact on other interfaces 

Depending on the power state of the UICC the following conditions for the interfaces shall apply: 

• If the UICC is in "low power mode" the terminal shall not activate the TS 102 221 [1] interface and if the 
UICC supports the USB interface according to TS 102 600 [6], it shall not perform an attachment on the USB 
interface. 

• If the UICC is in "full power mode", the terminal may independently activate any other UICC interfaces. 

• If the UICC was activated according to TS 102 221 [1], an additional activation of the SWP interface shall be 
considered as selected application on the UICC. 

6.2.4 Behaviour of a UICC in a terminal not supporting SWP 

The UICC shall take care of terminals having C6 contact connected with low impedance to Vcc or electrically isolated. 

When the UICC detects that the contact C6 is not connected to Vcc it shall connect the C6 contact with a low 
impedance to Gnd within 2 s after detecting that the terminal does not indicate the support of SWP interface. 

NOTE: Implementation has to take care to minimize SWP related power consumption. 

6.2.5 Behaviour of terminal connected to a UICC not supporting SWP 

When the terminal detects that the UICC does not support SWP, it shall keep SWIG in the deactivated state (state L). 

6.2.6 Inactive contacts 

The conditions for inactive contacts as defined in TS 102 221 [1] shall apply to contact C6. 
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Electrical characteristics 



7.1 



Operating conditions 



The voltage levels for the CLF (Master) and the UICC (Slave) signal SI are illustrated in figure 7.1. 



Vqh max 
1,8 V 

Vqh min 



^OL max 
Gnd 



CLF (Master) 

A 



UICC (Slave 

tac 
V 



Input voltage 



IH max 



Valid range for S1 high 



V 



IH min 



.V 



IL max 



Valid range for S1 low 



■V 



IL min 



Figure 7.1 : Voltage definitions for the signal S1 

Vjfj and VjL refers to the receiving device signal level (Slave). Vqjj and Vq^ refers to the sending device signal level 
(Master). All voltages are referenced to Gnd. 

The SWP interface uses a second signal S2 which is the current from the master to the slave and allows data to be sent 
back from the slave to the master. S2 values are defined when SI is state H. The current levels for S2 are defined in 
clause 7.1.4.1, as shown in figure 7.2. 



S2 (Current) 

A 



- 




H max 



H min 



L max 



L min 



Figure 7.2: Definitions of the current level for S2 on SWIO 

7.1.1 Supply voltage classes 

A UICC supporting the SWP interface shall support the voltage classes B and C, as defined in TS 102 221 [1]. 
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7.1.2 Vcc (C1) low power mode definition 

When the system operates in low power mode table 7.1 applies. 

Table 7.1 : Electrical characteristics of Vqq in low power mode 



Symbol 


Conditions 


Minimum 


Maximum 


Unit 


Vcc 


Class C 


1,62 


1,98 


V 


'cc 


Class C 




5 


mA 


NOTE: The current value is averaged over 1 ms. 



The maximum current in the table 7.1 is defined for the UICC. The terminal may deliver more. The voltage value shall 
be maintained within the specified range despite transient power consumption as defined in table 7.2. 

Table 7.2: Spikes on Iqq 



Class 


Maximum charge 
(see note 1) 


Maximum duration 


Maximum variation of Iqq 
(see note 2) 


C 


6 nA.s 


400 ns 


30 mA 


NOTE 1 : The maximum charge is half the product of the maximum duration and the maximum variation. 
NOTE 2: The maximum variation is the difference in supply current with respect to the average value. 



7.1.3 Signal S1 

SI is a signal in the voltage domain to transmit data from the CLF to the UICC on SWIO (contact C6). SI shares the 
same electrical contact as S2 as defined in clause 7.1.4. Electrical characteristics of SI are given in tables 7.3 and 7.4. 

Currents are considered positive, if they are flowing into the UICC or out of the CLF. 

Table 7.3: Electrical characteristics of SWIO for SI under 
normal operating conditions in voltage class B 



Symbol 


Parameter 


Conditions 


Minimum 


Maximum 


Unit 


VOH 


Output High Voltage (high) 


'imin- ' - 'hmax 

(see note 2) 


1,40 


1,98 (see note 1) 


V 


Vol 


Output Low Voltage (low) 


-20 |iA < 1 < |iA 


(see note 1 ) 


0,3 


V 


V|H 


Input High Voltage (high) 




1,13 


2,28 


V 


V|L 


Input Low Voltage (low) 




-0,3 


0,48 


V 


NOTE 1 : To allow for overshoot the voltage on SWIO shall remain between -0,3 V and Vq|_| ^^^ + 0,3 V during 

dynamic operation. 
NOTE 2: The values of l|_ ^j^ and I,., ^^^ ^^^ 9'^^"^ '"^ ^-"^ -^-^ ■ 



Table 7.4: Electrical characteristics of SWIO for SI under 
normal operating conditions in voltage class C 



Symbol 


Parameter 


Conditions 


Minimum 


Maximum 


Unit 


VoH 


Output High Voltage (high) 


'Lmin - ' - 'h max 

(see note2) 


0,85 X Vqq 


Vqq (see notel) 


V 


Vol 


Output Low Voltage (low) 


-20 |iA < 1 < |iA 


(see notel) 


0,15 X Vcc 


V 


V|H 


Input High Voltage (high) 




0,7 X Vcc 


Vcc+0,3 


V 


V|L 


Input Low Voltage (low) 




-0,3 


0,25 X Vcc 


V 


NOTE 1 : To allow for overshoot the voltage on SWIO shall remain between -0,3 V and Vqq+ 0,3 V during 

dynamic operation. 
NOTE 2: The values of l|_ ^j^ and I,., ^^^ ^^^ Q\yef^ in 7.1 .4.1 . 
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7.1.4 Signal S2 



S2 is a signal in the current domain to transmit data from the UICC to the master. S2 shares the same electrical contact 
as SI (contact C6). In this clause the electrical characteristics of S2 are described. 



7.1.4.1 



Operating current for S2 



S2 is considered as in state H when the current drawn on SWIO is between l^ ^^-^^ and Ijj ^^^ and is considered in state L 
when the current drawn on SWIO is between I^ ^[^ and I^ max- 

Table 7.5: Electrical characteristics of SWIO for S2 under normal operating conditions 



Symbol 


Parameter 


Conditions 


Minimum 


Maximum 


Unit 


Ih 


High Current 


V,Hmin ^ S1 < V,H^,, 


600 


1000 


^A 


II 


Low Current 


V,Hmin ^S1 < V,H^,, 





20 


^A 



8 



Physical transmission layer 



8.1 SI Bit coding and sampling time (Self-synchronizing code) 



The bit coding of SI is illustrated in figure 8.1. 



S1 




Logical 1 



Logical 



Figure 8.1 : Bit-coding of S1 

The nominal duration of the state H for a logical 1 is 0,75 x T, the nominal duration of the state H for a logical is 
0,25 X T. 

All bits shall be transmitted consecutively. A bit is defined as having two rising edges. These rising edges constitute the 
beginning and end of the bit period. The bit-duration may be different for each transmitted bit. 
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Figure 8.2: SI waveform 

The input capacitance of the UICC (C^q^j^ ) on the C6 contact shall not exceed 10 pF. Table 8.1 gives SI waveform 
timing. 

Table 8.1 : SI waveform timings 



Symbol 


Parameter 


Conditions 


Minimum 


Nominal 


Maximum 


Unit 


tf 


Fall time 


Cload^IOpF 
T < 5 000 ns 


5 ns 


- 


0,05 xT 




T > 5 000 ns 


5 ns 
(see note 3) 


- 


250 ns 
(see note 3) 




tr 


Rise time 


Cload^IOpF 
T < 5 000 ns 


5 ns 


- 


0,05 xT 
(see note 1 ) 




^LOAD^IOPF 

T > 5 000 ns 


5 ns 
(see note 3) 


- 


250 ns 

(see notes 1 

and 3) 




Thi 


Duration of the state H for 
coding a logical 1 of S1 




0,70 xT 


0,75 xT 


0,80 xT 




"•"ho 


Duration of the state H for 
coding a logical of S1 




0,20 xT 


0,25 xT 


0,30 xT 




T 
(see note 2) 


Default bit duration 




1 


- 


5 


\1S 


Extended bit duration 




0,590 


- 


10 


us 


NOTE 1 : Valid for the leading edge and the trailing edge of each bit. 
NOTE 2: Extended bit durations are indicated as per table 9.3. 

NOTE 3: These timing values shall also apply for SWIO contact activation and transitions to and from 
DEACTIVATED state. 
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8.2 S2 switching management 



S2 is valid only when SI is in state H. The UICC (Slave) shall only perform switching of S2 when SI is in state L, or 
when resuming SWP (the only occasion when S2 is allowed to be switched while SI is in state H due also to the 
SUSPENDED state of SWIO). Figure 8.3 illustrates the timing of S2 related to SI. 




S2 is valid 



S2 is not valid 



Figure 8.3: S2 timing 

8.3 SWP interface states management 

The SWP has three states: 
ACTIVATED: 

In this state master and slave are sending bits. 

SWP remains in this state until a SUSPEND transition occurs. 

SUSPENDED: 

In this state S 1 is in state H and S2 is in state L. This state is the initial state of SWP at activation of the SWP interface. 

SWP remains in this state until a RESUME or DEACTIVATE transition occurs. 
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DEACTIVATED: 

In this state the signal S 1 is in state L and the signal S2 is in state L. 

SWP remains in this state until an ACTIVATE transition occurs. 

NOTE: When the UICC is operating in full power mode, the master should not put SWP in that state if the 
terminal does not provide means for re-activation of this interface. 

The transitions between these states are defined as follows: 

RESUME: 

Transition from SUSPENDED state to ACTIVATED state. Both the master and the slave may execute a RESUME to 
bring SWP into ACTIVATED state. 

If the master has not received an upper layer indication that the UICC requires no more activity on this interface, the 
master resumes by sending a transition sequence followed by P2 consecutive idle bits. SWP enters the ACTIVATED 
state at the end of the last of these bits. 

If the master resumes, the slave may start sending frames already during the P2 idle bits. 

If the master has received an upper layer indication that the UICC requires no more activity on this interface then the 
master resumes by operating a SWIO deactivation and SWIO activation. 

The slave resumes by drawing a current (S2 in state H). The master shall respond by sending a transition sequence in 
less than P3j^^^ time. At the end of the transition sequence, SWP enters the ACTIVATED state. The delay after the 
transition sequence until the SOF sent by the slave shall not exceed 4 bits. 

Figure 8.4: Void 

SUSPEND: 

If there is no activity on SWP, other than idle bits during PI time, the master may switch SWP to the SUSPENDED 
state by maintaining SI in state H. 

DEACTIVATE: 

The master may switch SWP to the DEACTIVATED state by maintaining SWIO in state L for longer than P4 time if 
one of the following conditions is met: 

• The slave has indicated on a higher layer that no more activity is required on this interface and SWP has 
entered SUSPENDED state. 

• SWP is in SUSPENDED state for a time of PX and the CLF: 

does not detect an RF field compHant with ISO/IEC 14443-2 [2] or ISO/IEC 18092 [8]; or 

does not generate an RF field on request from the UICC. 

ACTIVATE: 

If SWP is in DEACTIVATED state, the interface activation procedure as described in clause 6.2.3 shall be applied. 
The slave may request activation of the interface by using the ACTIVATE command as defined in TS 102 223 [7]. 
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Figure 8.5 illustrates an example of SWP activities. 

S1 ACTIVATED 



^ P1 ^ 
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SUSPEND 



SUSPENDED 



Transition 
sequence 



ACTIVATED 



S2 
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by master 



SUSPENDED 



SUSPEND 



DEACTIVATED 



P4 



CL 


8 

CD 


c 

■s 


^ 


t 


S!i 


CO 




'■+-' 




r 








CD 



ACTIVATE 



PI Figure 8.5: SWB states and transitions P4 

Table 8.2 gives SWP management timings. 

Table 8.2: SWP Management Timing 



P2 



Symbol 


Parameter 


Minimum 


Maximum 


Unit 


P1 


Suspend sequence 


7 


- 


Bit 


P2 


Resume by master sequence 


8 


8 


Bit 


P3 


Resume by slave time 


- 


5 


\xs 


P4 


Deactivation time 


100 


- 


us 


PX 


SWP inactivity timeout 


15 


- 


ms 



8.4 Power mode states/transitions and Power saving mode 

When the terminal activates Vcc (contact CI) the UICC shall enter the initial power state with the current consumption 
of the UICC complying with the value in TS 102 221 [1] for "power consumption of the UICC during ATR at 4 MHz 
external clock frequency" . 

The UICC shall enter low power mode 

• when this mode is indicated in a power mode frame during initial SWP interface activation, or 

• when the UICC receives the first non-ACT frame without having received a power mode frame during initial 
SWP interface activation. 

The UICC shall enter full power mode: 

• when this mode is indicated in a power mode frame during initial SWP interface activation, or 

• if the conditions for full power mode on another interface are fulfilled. 

The CLF shall indicate full power mode if sufficient power from the terminal's power supply (e.g. battery) is available. 

During the initial power state, the UICC may already increase its current consumption to the value defined for low 
power mode as soon as it detects the SWP ACTIVATED state. 

Switching from full power mode to low power mode and vice versa requires deactivation of Vcc (contact CI). 
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The UICC shall be in power saving mode when all of the following conditions for activated interfaces are given: 

• clock stop mode according to TS 102 221 [1] if this interface is activated (if UICC is in full power mode); 

• suspend mode according to TS 102 600 [6] if this interface is activated (if UICC is in full power mode); 

• one of the following conditions is met: 

The SWP is in DEACTIVATED state for 10 ms. 

The last information received on SWP was the SHDLC acknowledgment to the indication by the upper 
layer that the UICC requires no more activity on this interface and the SWP is in SUSPENDED state for 
10 ms. 

When the UICC is in power saving mode it shall not exceed the current defined for clock stop mode in TS 102 221 [1] 
or the limit given for suspend mode in TS 102 600 [6] whatever the interface is activated. 

The UICC shall exit the power saving mode when at least one of the UICC interfaces is resumed from these conditions. 

NOTE: In full power mode, all the resources in the terminal (e.g. display, keyboard, etc.) may not be available for 
the UICC applications. 



Data link layer 



9.1 



Overview 



The Data Link layer manages LPDUs (Link Protocol Data Units) as illustrated in figure 9.1. This layer can be divided 
into two sub-layers: 

• MAC layer is in charge of framing. 

• LLC layer is in charge of error management and flow control. 





Packet 






;; 




LLC layer 




;; 






LPDU 






;: 




MAC layer 




;; 






Frame 





Figure 9.1 : Data link layer overview 



9.2 Medium Access Control (MAC) layer 
9.2.1 Bit order 

The bit order of the SWP communication channel is MSB first. 
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9.2.2 Structure 

Figure 9.2 illustrates the format of a frame sent from the master to the slave. 

Bit Stuffing 



SOF FLAG 



Payload 



CRC16 



EOF FLAG 



1111110 



1111111 



V 



y 



y 



6x1 7x 1 

Figure 9.2: Frame structure sent by master 

The SOF flag has the value 7E' and the EOF flag has the value 7F'. Between frames, idle bits (logical value 0) are sent. 
There is at least one idle bit between frames. 

Figure 9.3 illustrates the format of a frame sent from the slave to the master. 

Bit Stuffing 



SOF FLAG 



Payload 



CRC16 



EOF FLAG 



w 





1 


1 


1 


1 


1 


1 






1111111 



t 



V 



y 



y 



6x1 



7x1 



Wakeup sequence 



Figure 9.3: Frame structure sent by slave 

A wakeup sequence, consisting of a bit with logical value 1 shall be inserted before each frame sent from the slave to 
the master. 

In the case that the master starts suspending the interface at the same point in time when the slave starts sending the 
wakeup sequence, the bit with logical value 1 is transformed into a resume by slave sequence which brings SWP back 
to ACTIVATED state. 

The payload size is limited to 30 bytes. The CRC field is 16 bits long. 

9.2.3 Bit Stuffing 

In order to unambiguously detect the SOF and EOF flags, zero bit stuffing shall be employed by the transmitting entity 
when sending the payload and the CRC on SWP. After five consecutive bits with the logical value 1, a bit with the 
logical value is inserted. If the last five bits of the CRC contain the logical value 1, then no bit with the logical 
value will be added. The receiver shall recognize the stuffed bits and discard them. 
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An example of a zero bit stuffed sequence is given in figure 9.4. 
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Figure 9.4: Bit stuffing 



9.2.4 Error detection 



The detection of errors in a frame shall be based on the 16-bit frame checking sequence as given in ISO/IEC 13239 [5]. 
The CRC polynomial is: 

Xl6+xl2+x5+l. 

Its initial value is OxFFFF. 

The CRC is computed on the bits between SOF and EOF both excluded. 



9.3 Supported LLC layers 



Three Logical Link Control (LLC) layers using the previously defined MAC layer are defined in the present document: 

• SHDLC: This is the generic LLC used during most of the contactless transactions. SHDLC is defined in 
clause 10. Support of this LLC in mandatory in the CLF and the UICC. 

• CLT: This LLC is used for some proprietary protocol handling. CLT mode is defined in clause 11. Support of 
this LLC is optional in the CLF and optional (application dependant) in the UICC. 

• ACT: This LLC consist of frames used during interface activation. Support of this LLC is mandatory in the 
CLF and the UICC. 

Table 9.1 : LLC Control field coding 



Frame Types 


Bit Field 


8 


7 


6 1 5 1 4 1 3 1 2 1 1 


RFU 








All settings 


ACT 





1 


1 


ACT type 


CLT 





1 





CLT CMD 


SHDLC 


1 


All settings 



The control field is the first byte of the SWP frame payload. Definition for the different LLC layers can be found in 
table 9.1. 

The LPDUs payload shall be structured according to figure 9.5. 
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LLC CONTROL FIELD 



■^r 



ACT TYPE 



to 3 BYTES 



ACT PAYLOAD 



.^^ 



ACT LPDU 



LLC CONTROL FIELD 



J 



MAX 29 BYTES 



^r 



CLT CMD 



J^ 



CLT PAYLOAD 



CLT LPDU 



LLC CONTROL FIELD 



MAX 29 BYTES 



^Y^ 



U^ 



^r 



SHDLC 

CONTROL 

FIELD 



.y^ 



HDLC PACKET 



SHDLC LPDU 



Figure 9.5: LPDU structure of the 3 defined LLC layers 



9.3.1 Interworking of the LLC layers 



After SWIO (contact C6) activation or after the transition of SI to state H from DEACTIVATED state, the SHDLC 
link shall be not established and no CLT session shall be open. The ACT LLC shall be used by the UICC and by the 
CLF. 

The CLF shall take the following action after successful activation of the SWP: 

• If the CLF has data to be sent to the UICC (e.g. due to a contactless transaction) that requires the use of the 
CLT LLC, it shall initiate a CLT LLC session. 

• Otherwise it shall start the establishment of an SHDLC link as soon as possible. 

NOTE: The CLF will always send the first non-ACT frame after activation of the SWP. 

After the UICC and the CLF have established the SHDLC link or opened the CLT session, the UICC and the CLF shall 
not send ACT LLC frames; received ACT LLC frames shall be ignored. 

To enter the SHDLC LLC for the first time after SWP interface activation, the link establishment procedure as 
described in clauses 10.7.2 and 10.7.3 shall apply. 
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Once the SHDLC link is established, a CLT session shall not invalidate the SHDLC context and the endpoint 
capabilities negotiated during the SHDLC link establishment. 

To enter the CLT LLC from ACT LLC or SHDLC LLC, the CLT session shall be opened as described in clause 1 1.6. 
The CLF shall open a CLT session only when all SHDLC LFrames are acknowledged. SHDLC LLC frames received 
by the UICC or by the CLF during a CLT session close the CLT session. 

In case the UICC or the CLF receives a corrupted SWP frame, then the receiving entity shall use the error recovery 
procedure defined for the LLC of the last correctly received SWP frame. Immediately after SWIO (contact C6) 
activation or after the transition of S 1 to state H from DEACTIVATED state, the error handling of the ACT LLC shall 
apply. 



9.4 



ACT LLC definition 



The ACT LPDU shall be structured according to figure 9.6. 



ACT LLC CONTROL FIELD 

-^ ► 



ACT PAYLOAD 



■^r 



ACT_ 
CTRL 



ACT_DATA 
(0 to 2 Byte) 



ACTJNFORMATION 
(0 to 1 Byte) 



^A^ 



ACT TYPE 



ACT LPDU 



Figure 9.6: ACT LPDU structure 

Coding of ACT TYPE: 

• The meaning of FR in a frame when received by the UICC is described in clause 6.2.3. 1 . 

• Meaning of FR in a frame when received by the CLF: 

The CLF shall ignore the FR bit. 
A frame sent from the UICC to the CLF shall have the FR bit set to 0. 

• Meaning of INF in a frame when received by the CLF: 

INF = 1 : Last byte of ACT payload contains the ACTJNFORMATION field. 
INF = 0: ACTJNFORMATION field not available. 

• Meaning of INF in a frame when received by the UICC: 

The UICC shall ignore the INF bit. 
A frame sent from the CLF to the UICC shall have the INF bit set to 0. 
The meaning of ACT_CTRL and ACT_DATA is given in table 9.2. 
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Table 9.2: Meaning of ACT_CTRL and ACT_DATA 



ACT CTRL 


Meaning 


ACT DATA FIELD 


000 


ACT READY 
Sent from UlCCtoCLF 


OByte 


010 


ACT_POWER_MODE 

Sent from CLF to UICC to indicate the power 

mode for the UICC. 


1 Byte 

'00': Low power mode 

'01': Full power mode 

(see Note) 


001 


ACT_SYNC 

Sent from UICC to CLF to control the SYNCJD 

verification process. 


2 Byte SYNC ID 


All other values 
(see note) 






NOTE: All other values are reserved for future use. These values shall not be set by the transmitting entity and 
shall be ignored by the receiving entity. 



ACTJNFORMATION: By sending this field appended to an ACT_SYNC frame, the UICC indicates extended 
capabiHties as defined in table 9.3. 

Table 9.3: Extended capability indication in ACTJNFORMATION field 



Bit field 


Value 


Meaning 


8.-3 


000000 


RFU (see note) 


2 


1 




Extended SWP bit durations down to 0,590 |is are supported 

No lower extended SWP bit durations beyond the default range are 

supported 


1 


1 




Extended SWP bit durations up to 10 |is are supported 

No higher extended SWP bit durations beyond the default range are 

supported 


NOTE: These bits shall not be set by the UICC and shall be ignored by the CLF. 



The CLF may use extended SWP bit durations as indicated in the ACTJNFORMATION field after it has received an 
ACT_SYNC frame with an ACTJNFORMATION field during the initial interface activation. 



9.4.1 SYNCJD verification process 



The purpose of the SYNCJD verification is to check the identity of the UICC. The SYNCJD verification process 
consists of the following steps: 

• The UICC presents the SYNCJD to the CLF in an ACT_SYNC frame. The presented SYNCJD is named 
verification data. 

• The CLF compares verification data with identity reference data. The provisioning of the identity reference 
data is out of scope of the present document. 

For the SYNCJD verification, the following conditions shall apply: 

• The CLF and the UICC shall support SYNCJD verification. 

• The SYNCJD verification shall always be executed when the SWP interface is activated (see clause 6.2.3). 

The CLF shall perform the SYNCJD verification process based on ACT frames received from the UICC as outlined 
below: 

• In case an ACT_SYNC frame is received, the CLF shall use the ACT_DATA field as verification data. 
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If the CLF evaluates that verification data and identity reference data values are equal, the identity check is successful. 

If the values are not equal, the identity check failed and the CLF shall not open a CLT session. 

NOTE: Within the scope of the present document, only the mechanism that the CLF checks the identity of the 

UICC is described. The consequences of a failed identity check and mechanisms to recover from this state 
are specified in a higher layer. 



10 SHDLC LLC definition 
10.1 SHDLC overview 

The SWP SHDLC layer as defined in the present document is a simplified version of ISO's High-level Data Link 
Control (HDLC ISO/IEC 13239 [5]) specification. It is responsible for the error- free transmission of data between 
network nodes. 

The SHDLC layer shall ensure that data passed up to the next layer has been received exactly as transmitted (i.e. error 
free, without loss and in the correct order). Also, the SHDLC layer manages the flow control, which ensures that data is 
transmitted only as fast as the receiver may receive it. 

SHDLC ensures a minimum of overhead in order to manage flow control, error detection and recovery. If data is 
flowing in both directions (full duplex), the data frames themselves carry all the information required to ensure data 
integrity. 

The concept of a sliding window is used to send multiple frames before receiving confirmation that the first frame has 
been received correctly. This means that data may continue to flow in situations where there may be long "turnaround" 
time lags without stopping to wait for an acknowledgement. 



10.2 Endpoints 



SHDLC communication occurs between two endpoints. Those endpoints are identified as the CLF and the UICC. There 
is no priority of traffic. 



CLF UICC 

SHDLC 





Figure 10.1: Endpoints 



10.3 SHDLC frame types 



SHDLC uses several types in order to transfer data and to manage or supervise the communication channel between the 
two endpoints (ends of the communication channel): 

• I-Frames (Information frames): Carry upper-layer information and some control information. I-frame 
functions include sequencing, flow control, and error detection and recovery. I-frames carry send and receive 
sequence numbers. 

• S-Frames (Supervisory Frames): Carry control information. S-frame functions include requesting and 
suspending transmissions, reporting on status, and acknowledging the receipt of I-frames. S-frames carry only 
receive sequence numbers. 

• U-Frames (Unnumbered Frames): Carry control information. U-frame functions include link setup and 
disconnection, as well as error reporting. U-frames carry no sequence numbers. 
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10.4 Control Field 

The SHDLC control field has the structure described in table 10.1, including the first bits of the payload. 

Table 10.1 : SHDLC Control field coding 



Frame Types 


Bit Field 


8 


7 


6 1 5 1 4 


3 1 2 1 1 


1 


1 





N(S) 


N(R) 


S 


1 


1 





TYPE 


N(R) 


U 


1 


1 


1 


M 



where: 

• N(S): Number of the information frame. 

• N(R): Number of next information frame to receive. 

• TYPE: Type of S-Frame. 

• M: Modifier bits for U-Frame. 

The size of the sliding window is four frames by default. Frames types may be interleaved. For example, a U-Frame 
may be inserted between I-Frames. 

10.4.1 I-Frames coding 

The functions of the information command and response is to transfer sequentially numbered frames, each containing 
an information field, which might be empty, across the data link. 



1 0.4.2 S-Frames coding 



Supervisory(S) commands and responses are used to perform numbered supervisory functions such as acknowledgment, 
temporary suspension of information transfer, or error recovery. Frames with the S format control field do not contain 
an information field. 

Supervisory Format commands and responses are as follows: 

• RR: Receive Ready is used by an endpoint to indicate that it is ready to receive an information frame and/or 
acknowledge previously received frames. 

• RNR: Receive Not Ready is used to indicate that an endpoint is not ready to receive any information frames. 

• RE J: Reject is used to request the retransmission of frames. 

• SREJ: Selective Reject is used by an endpoint to request retransmission of specific frames. An SREJ shall be 
transmitted for each erroneous frame; each frame is treated as a separate error. Only one SREJ shall remain 
outstanding on each link direction at any one time. 

The type coding is given by the table 10.2. 

Table 10.2: Type coding of the S-frames 



Frames 


Type 


Status 


RR 


GO 


Mandatory 


REJ 


01 


Mandatory 


RNR 


10 


Mandatory 


SREJ 


11 


Optional 



Optional type of frame shall not be used before capability negotiation is defined during initialization. 
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1 0.4.3 U-Frames coding 

The unnumbered format commands and responses are used to extend the number of data Hnk control functions. The 
unnumbered format frames (see clause 10.4) have 5 modifier bits which allow for up to 32 additional commands and 
responses. Only a subset of the HDLC commands and responses are used for SHDLC: 

• RSET: Reset of the data link layer is used to reset the sequence number variables in the both endpoints. 

• UA: Unnumbered Acknowledgment is used to acknowledge the receipt and acceptance of a RSET command. 

Table 10.3: Modifier coding of the U-frames 



Frames 


IVIodifier 


status 


RSET 


11001 


Mandatory 


UA 


00110 


Mandatory 



1 0.5 Changing sliding window size and endpoint capabilities 

The sliding window size is negotiated during SHDLC session establishment. The validity of the negotiated window size 
starts with completing a successful session establishment and ends with the interface deactivation or with a new 
SHDLC session re-establishment. The sliding window size may be lower than the default value due to limited 
resources. In consequence, an endpoint may want to ask the other endpoint to lower the sliding window size. 

The RSET frame may carry a configuration field in order to change the sliding window size (down to 2). If the default 
size (in case of an RSET command without configuration field) or the size provided is too large at a RSET frame 
reception, the receiver shall not acknowledge it. Instead, the receiver shall send a RSET frame with an appropriate 
sliding window size (which is lower than the window size offered by the other endpoint). 

An endpoint shall obey to window size reconfiguration if the requested window size is lower than its default 
configuration. It acknowledges the new size with a UA frame. 

SREJ support is negotiated in the same way. The RSET frame may carry a configuration field in order to indicate the 
capability of the endpoint to support this frame. If one or more of the indicated endpoint capabilities are not supported 
by the receiving endpoint, it shall answer with a RSET frame indicating only the supported endpoint capabilities. In this 
case the RSET response may contain the same window size. 

1 0.5.1 RSET frame payload 

The RSET frame has 2 optional bytes in order to provide the endpoint window size and capabilities. The number 
provided for the endpoint window size shall be between 2 to 4 inclusive. In case this RSET frame is sent in response to 
a received RSET frame, the endpoint window size value shall be equal to or lower than the previously provided value. 
A RSET frame response shall not indicate the same window size and the same endpoint capabilities as the received 
RSET frame; in such a case a UA frame shall be sent. The second optional byte may be sent after the window size by 
the endpoint in order to indicate support of optional endpoint capabilities. If it is absent, the default values apply. 
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Window Endpoint 

RSET size capabilities 



1111 1001 


nnnn nnnn 


b8...bi 


8 bits 


8 bits 


8 bits 









2<nnnn nnnn<4 



Figure 10.2: RSET frame payload 
Table 10.4: Bit coding of optional endpoint capabilities 



Bit 


Default 
value 


Description 


1 





Support of Selective Reject S-frame (SREJ) 

0: Not supported (default) 

1 : Supported 


2 to 8 


000000 


RFU 



10.5.2 UA frame payload 

The UA frame carries no payload. 

10.6 SHDLC context 

The SHDLC context is defined by constant values such as the timeouts and the sliding window size as well as a number 
of variables as defined below. 

10.6.1 Constants 

• w: Sliding window size, w = 4 by default 

This value is not actually constant because it may be reduced at link establishment. However, up to the next 
reset of the SHDLC session, it never changes. 

• Tl: Acknowledge time. 

Lframes shall be acknowledged within Tl to avoid that the traffic stops. The Tl value is bound to the w value. 
Tl <5ms X w / 4. 

The acknowledge time is defined from the last bit of the EOF of the Lframe to be acknowledged to the first bit 
of the SOF of the frame providing the acknowledgement. 

• T2: Guarding/transmit time. T2>10ms 

If the Lframes are not acknowledged, an endpoint shall retransmit these frames. This value defines the time to 
wait. 72 is unaffected by modifications of w. 

The guarding/transmit time is defined from the last bit of the EOF of the not acknowledged Lframe to the first 
bit of the SOF of the retransmitted frame. 

• T3: Connection time. T3 <5 ms 

Used at link establishment, retry to setup link if the targeted endpoint did not answer with an UA frame or a 
RSET frame within T3. T3 is unaffected by modifications of w. 

The connection time is calculated from the last bit of the EOF of the RSET frame to the first bit of the SOF of 
the response frame. 
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10.6.2 Variables 

These three variables are modulo 8 and hold sequence numbers. 

• N(S): Sequence number for emission. Used in I Frames. Incremented after emission of the frame. 

• N(R): Next sequence number for reception. Used in I and S type frames. 

During full duplex data transmission or by emission of a S type frame, all received frames with a sequence 
number lower than N(R) are acknowledged. 

• DN(R): Lowest unacknowledged sequence number. 

Acknowledgements are outstanding for frames with sequence number greater or equal to DN(R) and lower 
than N(S). 

To know if a frame is in the window, sequence numbers are compared using modulo 8. The definition used for 
X<Y <Z modulo 8 is as follows: 

• If X < Z then the equation to calculate is: X < 7 < Z. 

• Otherwise the equation to calculate is: 7 > X or 7 < Z. 

10.6.3 Initial Reset State 

The following initial states shall apply in every endpoint after successful link establishment: 

• N(S) = N(R) = DN(R) = 0. 



1 0.7 SHDLC sequence of frames 
10.7.1 Nomenclature 




Frame Boundaries 




Transmission 
error 



Frame with 
Information 



Frame without 
Information 



Figure 10.3: Frames representation 
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Information frame: 

Receive Ready: 

Reject: 

Reset (no payload): 



I N(S), N(R) 



RR N(R) 



REJ N(R) 



RSET 



Receive and Not 
Ready: 

Selective Reject: 
Reset (with payload): 



RNR N(R) 



SREJ N(R) 



RSET 



WS4 



Figure 10.4: Frames type description 

1 0.7.2 Link establishment with default sliding window size 

An endpoint establishing an SHDLC link shall initiate link establishment by sending a RSET frame. 

If the SHDLC frame exchange on the link enters into an error condition which cannot be recovered by other SHDLC 
means, an endpoint may also reset and re-establish the link by sending a RSET frame. All buffered frames (received out 
of order or stored in the retransmission queue) shall be discarded. The upper layer shall be informed of the link reset. 

If the target is ready, it shall answer with a UA frame. The link is established after receiving this acknowledgment. 

Before link establishment, all frames except RSET from other endpoint shall be discarded. The connection timeout is 
required in order to detect failure and restart the operation. In this example, both endpoints work with the default 
window size and the UICC does not send a RSET frame because it received a RSET frame first and agreed on the 
default window size. 



iRSETi 



CLP: 



UICC: 



_Connection_ 
timeout 



|RSET| 



_Unlimited_ 
time 



10,0 



UA. 



Figure 10.5: Link establishment restart after UA loss 

Simultaneous resets are handled gracefully. After both endpoints send UA frames, link is established using the default 
window size. 



CLP: 



UICC: 



|RSET| 

n 



UA. 



UA. 



Unlimited_ 
time 



10,0 



n R 

Figure 10.6: Link establishment with crossover RSET frames 

1 0.7.3 Link establishment with custom sliding window size 

If the UICC has a smaller window size than the CLE, it ignores the received RSET frame. The CLE sees the customized 
RSET frame, changes its window configuration to 2 and sends an UA frame to establish the link. 
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9 1 UA| I i^ii^it^H I 10,0 

I 1 time I 



iRSET. 

UICC: 

' WS2 1 Ignore the received RSET. 

Request a smaller sliding 
window size. 

Figure 10.7: Link establishment with sliding window size of 2 

In case of RSET frames crossover, the mechanism still works. 

Change to a lower sliding 
window size. 

RSET. lUAj MnlimitoH I 'O'O I 



CLF: I 1 r^ ^^" 



B l UM I 

iRSETi 
I WS2 I 



|RSET 

UICC 

IWS2 



Ignore the received RSET. 



Figure 10.8: Link establishment with sliding window 
size of 2 and RSET frames crossover 

In case of frame loss, the link establishment restarts and link configuration is finally completed. 

UA| 



CLF: 


RSET 

M 

WS4 


Connection 
timeout 


RSET 

► 

WS4 


RSET 


UICC: 


\M 






WS2 



n 



Figure 10.9: The RSET frame from the UICC is lost 

9 1 UA I I UA I 



CLF: 

IWS4 



iRSET. ^ 

I wnn- \ I ^ Connection 

UIUU. r^ .. . — 

Iws2l timeout 



Figure 10.10: The UA from the CLF is lost and the connection timeout 
allows restarting the link configuration 

10.7.4 Dataflow 

Once the link is established, both endpoints may exchange data. 

The CLF sends a stream of data. The UICC has no data to send. So, the piggyback mechanism is not used (Frames are 
acknowledged using information frames going in the opposite way). The UICC shall acknowledge frame reception 
regularly in order to avoid traffic stop. An acknowledge timeout is used in order to send RR frames to the CLF. The 
timeout starts at the first received packet after the previous acknowledgement (other RR frame or piggybacking). If the 
UICC sends information frames (not shows here), the acknowledge timeout shall be stopped as piggybacking will 
acknowledge received frames. 
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10,0 



11,0 



12,0 



13,0 



14,0 



15,0 



16,0 



17,0 



10,0 



11,0 



CLF: 



UICC: 



acknowledge 


RR3 

— ► 


^ 













acknowledge 


RR6 







_acknowledge 
timeout 



■-^ 



Figure 10.11 : One way data flow with RR frames acknowledgement 

The acknowledge timeout shall not be too long to avoid throughput degradation. Otherwise, the sending endpoint will 
be waiting for the destination to become ready. This diagram shows what happens with a sliding window size of 4 and a 
timeout value that is too large. 



10,0 



CLF: 



Traffic is suspended 
I 13,0 I 



14,0 



15,0 



16,0 



UICC: 



_acknowledge_ 
timeout 






Figure 10.12: One way data flow with too long a time for acknowledgement 

In this example, I-Frames flow in both ways. Piggybacking is used to acknowledge received frames during I-Frames 
crossover. Because of last packets crossover, both endpoints use acknowledge timeout to detect when to send a 
RR frame after traffic ends. 



CLF: 



10,0 


11,0 


12,0 


13,0 


14,1 










M 



Acknowledge_ 
timeout 



RR3 



10,2 


11,3 
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knowledge 


RR5 


timeout 









UICC: 



Figure 10.13: Piggybacking and timed acknowledgement 

10.7.5 Reject (go N back) 

When a frame gets lost in the stream, the destination (here the UICC) will see a gap in the received frame numbers. If 
SREJ is not supported or if several frames got lost, the destination shall send a REJ frame as soon as possible in order to 
restart the stream at the first missing frame. 

I 1 Retransmissions 



CLF: 



10,0 


11,0 


12,0 


W/ 


14,1 








/v 





13,3 


14,4 







UICC: 



10,2 


11,3 


12,3 


REJ3 


13,3 















RR5 




acknowledge 

timeout 





L 



UICC saw frame 4 before 
frame 3. 



Figure 10.14: Piggybacking with reject frame after mismatching sequence number 
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10.7.6 Last Frame loss 

Each frame shall have a guarding/transmit timeout in order to retransmit frames if the destination does not notice a loss. 
When the last frame is lost, the destination endpoint will not be able to detect it. A RR frame shall be sent to 
acknowledge the last frame but a lost frame will never be requested for retransmission by the destination endpoint by 
using a reject mechanism. 



I 10,0 I 11,0 I 12,0 I 13,0 I \\A/ 
CLF: 



W- 



I 10,2 I 11,3 I 12,4 
UICC: ■ 







1 — 


Retransmission 


Transmit 

" timeout 


— ►- 


14,3 


acknowledge 

^ timeout ^ 



Figure 10.15: Last frame loss in piggybacking situation 

The acknowledgment by the CLF of the last frame sent from the UICC with a frame RR3 is not shown in the figure but 
shall be sent by the CLF before the acknowledge timeout. 

Figure 10.16 shows the same behaviour when the destination endpoint do not send any traffic (i.e. no piggybacking). 

I Retransmission 

I 10.0 I 11.0 I 12,0 I 13,0 I 140/ I Tronerv^it I '4,0 | 

CLF: ■ ■ ■ ■ J\ L V f A ■ 

I I I I I / K I timeout I I 

BiRR4| iRR5| 
acknowledge acknowledge 
"^ timeout ^1 "^ timeout ^1 

Figure 10.16: Last frame loss in one way data flow 

1 0.7.7 Receive and not ready 

Receive-not-ready (RNR) acknowledges an I-frame, as with RR, but also asks the peer endpoint to suspend 
transmission of I-frames. 

Stop sending frame — i i — Resume traffic 

10,0 I 11,0 I 12,0 I 13,0 I 14,0 I 15,0 . i 16,0 i 17,0 . 



CLF: 



UICC: 



acknowledge 


RR3 







| RNR4 . RR6 



Figure 10.17: Stop and resume traffic at UICC request 

The RR frame that follows an RNR frame shall be retransmitted every 5 to 20 ms (defined from the last bit of the EOF 
to the first bit of the SOF) until a new I frame is received. This avoids deadlock situations that could occur if an RR 
frame that is sent to resume the traffic gets lost. If the entity that received the RR has no more data to send, it shall send 
an I-frame with empty information field to signal the proper reception of the RR frame. 
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10.7.8 Selective reject 

Selective reject (SREJ) is used to request retransmission of just a single frame. 



10,0 I 11,0 I 12,0 I I3|,0/ I 14,1 I 15,2 



CLF: 



UICC: 



13,3 



10,2 I 11,3 I 12,3 



13,3 



_acknowledge_ 
timeout 



iRR6| 



UICC saw frame 4 
before frame 3. 



Figure 10.18: One frame loss in stream 

The acknowledgment by the CLF of the last frame sent from the UICC with a frame RR4 is not shown in the figure but 
shall be sent by the CLF before the acknowledge timeout. 

10.8 Implementation model 

All calculations on sequence numbers in this clause are done modulo 8. 

10.8.1 Information Frame emission 




Figure 10.19: Information frame emission. 
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10.8.2 Information Frame reception 




Receive a frame Ix 




YES 



Discard 



YES 



Send REJn 



YES 



SetT1 



Process frame I 



N(R) = N(R) + 1 




YES 



Deactivate all T2 for 
frames DN(R) to Y-1 



DN(R)=Y 




Figure 10.20: Information frame reception 

If support for Selective Reject S-frames was negotiated for the link and X is exactly one higher than N(R), a SREJj,^/j^x 
shall be sent instead of the REJjs^/j^x, the received I-frame shall be buffered and Y shall be evaluated as defined above. 
Once the frame with X = N(R) is received, the buffered I-frame shall also be processed. 
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10.8.3 Reception Ready Frame reception 




Deactivate all T2 for 
frames DN(R) to Y-1 



DN(R)=Y 



Figure 10.21 : RR frame reception 



1 0.8.4 Reject Frame reception 





YES ► 



Deactivate all T2 for 
frames DN(R) to N(S)-1 



DN(R) = N(S)=Y 



Retransmit frames 
starting from N(S) 



Figure 10.22: REJ frame reception 
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10.8.5 Selective Reject Frame reception 




YES- 



Deactivate all T2 for 
frames DN(R)to Y 



DN(R) = Y 



Retransmit frame Y 



Figure 10.23: SREJ frame reception 



1 0.8.6 Acknowledge timeout 




Timeout of T1 



Transmit RR N(R) 




Figure 10.24: Acknowledge timeout 
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1 0.8.7 Guarding/transmit timeout 



Timeout of T2 for frame X 



Resend I > 



Set T2 for this frame 




Figure 10.25: Guarding/transmit timeout 



11 



CLT LLC definition 



11.1 System Assumptions 

Void. 

1 1 .2 Overview 

The CLT LLC is used to exchange data based on SWP physical layer between the CLF and the UICC. The CLF acts as 
a bridge, which composes/removes the type specific RF-frame encapsulation, but keeps the type-specific error detection 
code, which is managed by the UICC except where specified otherwise. 

A minimum set of administrative commands is specified as well. 

A CLT session is defined as the sequence of frames based on CLT LLC. 



1 1 .2a Supported RF protocols 



• The CLT LLC supports transport of data for ISO/IEC 14443-3 [3] Type A based card emulation protocols. 

Initialization (anticollision and selection) of RF protocols is performed by the CLF without UICC 
involvement. The CLF possesses all information necessary. 

• The CLT LLC supports transport of data for the initialization commands of ISO/IEC 18092 [8] 
212 kbps/424 kbps passive mode based card emulation protocols. 

The UICC provides initialization data to the CLF, which performs RF protocol initialization. 

NOTE: In the present document, other RF protocols are not specified in detail, but are not excluded from being 
operated via CLT, as there are (e.g.) ISO/IEC 14443-2 [2] and ISO/IEC 14443-3 [3] Type B based 
schemes, as long as the maximum RF frame length (including error detection code) of the supported 
RF protocol does not exceed the transport capability of a single CLT frame and the CLF supports the 
proper RF protocol initialization. 
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1 1 .3 CLT Frame Format 

For CLT LLC frame format see figure 9.5. 

The CLT PAYLO AD may contain data transferred from or to the RF side of the CLF, furthermore referenced as 
DATA_FIELD. The structure of the DATA_FIELD shall either be "byte aligned" or retrieved from 
ISO/IEC 14443-3 [3] Type A standard frame format, furthermore referenced as "Type A aligned". 

For Type A aligned structure, meaningless bits in the last byte of the CLT PAYLO AD shall be padded with 0. See 
clause 1L5.1 for interpretation rules and an example. 

The CLT CMD shall indicate the type of data in the DATA_FIELD and may include additional administrative 
commands exchanged between the CLF and the UICC, referenced as ADMIN_FIELD. The interpretation of the 
DATA_FIELD and the ADMIN_FIELD is linked to the entity which has submitted the CLT frame (either the UICC or 
the CLF). 



Byte1 



Byte 2 



ByteN 



b8 (MSB) 



b1 b8 



b1 



b8 



(LSB) b1 



CLT LPDU with DATA_FIELD „Type A aligned" structured 






1 








ADMIN_FIELD 




Meaningless bits 






DATA_FIELD 
X bytes + (1 to 8) valid bits in last byte, starting from LSB 



CLT LPDU with DATA_FIELD „byte aligned" structured 






1 





1 


ADMIN_FIELD 


DATA_FIELD (M bytes) 



Figure 11.1: Typical examples for CLT frames with DATA_FIELD present 
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11.4 CLT Command Set 

Table 11.1 gives the coding of the CLT CMD field. 

Table 11.1: Contents of CLT CMD 



Bit 


Value 


Meaning 


5 




1 


Structure of DATA_FIELD in CLT PAYLOAD 
Data structure Type A aligned (see clause 1 1 .5.1) 
Data structure is byte aligned 


4to1 




ADMIN FIELD 


0000 
1000 

1001 

Other Values 


Interpretation of ADMIN_FIELD sent by the CLF to the UICC: 

No administrative command 

CL_PROTO_INF(A): The CLF was selected in ISO/IEC 14443-3 Type A [3] technology (see 

clause 11.5.3.1) 

CL_PROTO_INF(F): The CLF forwards initialization data according to ISO/IEC 18092 [8] 

212 kbps/424 kbps passive mode (see clause 1 1 .5.3.2) 

RFU 

Those values shall not be sent by the CLF. The rules for the UICC are described in 

clause 11.6.2. 


0000 
0001 

0010 

Other Values 


Interpretation of ADMIN_FIELD sent by the UICC to the CLF: 

No administrative command 

CL GOTO INIT: Requests transition of the CLF to initial state of the RF protocol initialization 

sequence (ISO/IEC 14443-3 [3]) 

CL_GOTO_HALT: Requests transition of the CLF to "HALT" state of the RF protocol 

initialization sequence (ISO/IEC 14443-3 [3]) 

RFU 

Those values shall not be sent by the CLF. The rules for the UICC are described in 

clause 11.6.2. 



NOTE: Independent from the content of the ADMIN_FIELD, CLT frames may provide a DATA_FIELD. 

1 1 .5 CLT Frame Interpretation 

1 1 .5.1 CLT frames with Type A aligned DATA_FIELD 

For CLT frames with Type A aligned DATA_FIELD, the bit count shall be retrieved implicitly from the byte length of 
the CLT PAYLOAD, where the interpretation rule depends on the direction the frame is transferred. 

For CLT frames sent from the CLF to the UICC the following table shall apply. 
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Table 11.2: Bit length calculation of Type A aligned frame (direction CLF to UICC) 



Size [bytes] of 
CLT PAYLOAD 


Number of RF bits interpreted 
as DATA_FIELD by the UICC 


Remark 





Invalid 




1 


7 (starting from LSB) 




2 


9 


1 RF byte + 1 parity bit 


3 


18 


2 RF bytes + 2 parity bits 


...4to8... 


(continue similar way) 




9 


72 


8 RF bytes + 8 parity bits 


10 


Invalid 




11 


81 


9 RF bytes + 9 parity bits 


...12to17... 


(continue similar way) 




18 


144 


16 RF bytes + 16 parity bits 


19 


Invalid 




20 


153 


17 RF bytes + 17 parity bits 


...21 to 26... 


(continue similar way) 




27 


216 


24 RF bytes + 24 parity bits 


28 


Invalid 




29 


225 


25 RF bytes + 25 parity bits 



For CLT frames sent from the UICC to the CLF the following table shall apply. 

Table 11.3: Bit length calculation of Type A aligned frame (direction UICC to CLF) 



Size [bytes] of 
CLT PAYLOAD 


Number of RF bits interpreted 

as DATA FIELD and thus 

sent to the PCD by the CLF 


Remark 








Interpretation rule see clause 1 1 .5.2 


1 


4 (starting from LSB) 




2 


9 


1 RF byte + 1 parity bit 


3 


18 


2 RF bytes + 2 parity bits 


...4to28... 


(continue similar way) 




29 


225 


25 RF bytes + 25 parity bits 



Below, the CLT frame layout transporting 4 RF bytes + 4 parity bits is shown as an example. 



Reception of 1801 4443 Type A frame via RF (w/o MAC layer): 

I Byte1 1 I Byte2 



ByteS 



Byte4 



LSB 



MSB LSB 



MSB LSB 



MSB LSB 



MSB 



RF-Byte 1 


P 
1 


RF-Byte 2 


P 
2 


RF-Byte 3 


P 
3 


RF-Byte 4 


P 
4 



Note: Pn ...Parity Bit for RF-Byte n 



CLT LPDU via SWP in "IS014443 Type A" structured: 

I Byte1 1 Byte2 1 Byte3 



Byte4 



ByteS 



Byte6 



RF-Byte 1 



RF-Byte 2 



RF-Byte 3 



RF-Byte 4 



Figure 1 1 .2: Example for a Type A aligned CLT frame 



b8 


(MSB) 




b1 (LSB) 


b8 


b1 


b8 


b1 


bS 




b1 


b8 




b1 


bS 










b1 





1 








ADMIN 


1 1 1 1 1 1 1 
1 1 1 1 1 1 1 


1 1 1 1 1 1 
1 1 1 1 1 1 


P 
1 


1 1 1 1 1 
1 1 1 1 1 


P 
2 




1 1 1 1 
1 1 1 1 


P 
3 


' 














P 
4 


1 1 
1 1 
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1 1 .5.2 Handling of DATA_FIELD by the CLF 

Due to the nature of RF protocols, the information exchange on RF side is half-duplex, where the PCD sends a 
command and the PICC sends normally a response, but also may not respond to erroneous frames or to certain 
commands. 

In the architecture described in the present document, the response or the condition not to respond shall be evaluated by 
the UICC. This condition shall be reported to the CLF by means of a CLT frame without a DATA_FIELD. 

The resulting data exchange flow for ISO/IEC 14443-3 [3] based card emulation protocols is as follows: 

• After the CLF has received an RF frame, a CLT frame with all RF data in the DATA_FIELD shall be 
composed and sent to the UICC. See clause 1L5.3.1 for different handling of the first frame after RF protocol 
initialization. 

• After reception of a CLT frame from the UICC, the CLF shall transmit the received data via RF if the CLT 
frame included a DATA_FIELD, if no DATA_FIELD was present then no data shall be transmitted via RF. 

The data exchange flow for ISO/IEC 18092 [8] 212 kbps/424 kbps passive mode card emulation protocols is described 
in clause 11.5.3.2. 

1 1 .5.3 Handling of ADMIN_FIELD 
11.5.3.1 CL_PROTO_INF(A) 

With this ADMIN_FIELD, the CLF shall inform the UICC about the presence of an ISO/IEC 14443-3 [3] Type A 
based card emulation RF protocol to be processed in CLT mode. 

In this case, CL_PROTO_INF(A) shall be sent by the CLF to the UICC after every successful ISO/IEC 14443-3 [3] 
Type A RF protocol initialization. 

During ISO/IEC 14443-3 [3] Type A RF protocol initiaUzation, the CLF shall not send CLT frames. 

Following actions shall be taken by the CLF on reception of the 1^^ RF frame after it has sent the "SAK" as per 
ISO/IEC 14443-3 [3] Type A: 

• The CLF shall verify the correctness of the next received RF frame. 

• If the error detection code is correct and the RF frame is a Type A standard frame as per ISO/IEC 14443-3 [3] 
with CRC_A appended, and the first byte is not 'EO', '50', '93', '95' or '97', the CLF shall compose a CLT frame 
with ADMIN_FIELD CL_PROTO_INF(A) and shall attach the received RF data as DATA_FIELD. The RF- 
type specific error detection code shall not be included and the DATA_FIELD shall be coded in "byte-aligned" 
manner. 

NOTE 1: Type A standard frames with the first byte equal to '50', '93', '95' or '97' represent commands belonging to 
the command set used for Type A RF protocol initialization as per ISO/IEC 14443-3 [3]. 

If the first byte is equal to 'EO' (command "RATS" as per ISO/IEC 14443-4 [4]), then the CLF shall 
continue ISO/IEC 14443-4 [4] processing using a higher level protocol out of scope of the present 
document, no CLT frame shall be sent to the UICC. 

NOTE 2: For protocols according to ISO/IEC 18092 [8] 106 kbps passive mode, the sequence containing the 
command code 'D400' (ATR_REQ) is treated in a similar way. 

If the length of the RF data exceeds the maximum size of the DATA_FIELD, no CLT frame shall be sent 
to the UICC. 

The following actions shall be taken by the UICC on receiving a CLT frame with ADMIN_FIELD 
CL_PROTO_INF(A): 

• The contents of the DATA_FIELD shall be evaluated by the UICC: 

If the contents of the DATA_FIELD is a valid command for one of the RF protocols supported by the 
UICC, the UICC shall compute the response and send it to the CLF within a CLT frame. 
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If the contents of the DATA_FIELD is equal to ISO/IEC 14443-3 [3] command "HALT", the UICC shall 
reply with a CLT frame with the ADMIN_FIELD CL_GOTO_HALT. 

In any other case, the UICC shall send a CLT frame with the ADMIN_FIELD CL_GOTO_INIT. 

1 1 .5.3.2 CL_PROTO_INF(F) 

With this ADMIN_FIELD command, the CLE shall inform the UICC about the presence of a ISO/IEC 18092 [8] 
212 kbps/424 kbps passive mode based card emulation protocol, for which the initialization data shall be provided by 
the UICC via CLT as described below. 

A CLT frame with the ADMIN_EIELD CL_PROTO_INE(E) shall be sent by the CLE to the UICC after every 
reception of an anticollision command ("POLLING REQUEST" command) from RE side if the CLE is configured to do 
so. This information is retrieved from higher application layers. 

In this case, the following actions shall be taken by the CLE: 

• When the CLE has received the initialization command as defined in ISO/IEC 18092 [8] for 

212 kbps/424 kbps passive mode ("POLLING REQUEST", command code '00'), it shall forward the received 
RE data (including the LEN and RE CRC field) to the UICC encapsulated as byte aligned DATA_EIELD in a 
CLT frame with the ADMIN_EIELD CL_PROTO_INE(E). 

• On reception of a CLT frame with ADMIN_EIELD (OOOO)b, the CLE shall interpret the DATA_EIELD as 
initialization response ("POLLING RESPONSE", Command Code '01', including the LEN and RE CRC field), 
and send it out on RE side according to the initialization procedure as defined in ISO/IEC 18092 [8] for 

212 kbps/424 kbps passive mode. 

NOTE: According to ISO/IEC 18092 [8], the initiaHzation response ("POLLING RESPONSE") is received by the 
initiator after a waiting time of 2,417 ms (512 x 64 / 13,56 MHz) within one of the allowed time slots. 
Each time slot has a duration of 1,208 ms (256 x 64 / 13,56 MHz). The CLE randomly selects one of the 
available time slots indicated by the PCD within the anticollision command. 

The following actions shall be taken by the UICC on receiving a CLT frame with ADMIN_EIELD 
CL_PROTO_INE(E): 

• The contents of the DATA_EIELD shall be evaluated and the ISO/IEC 18092 [8] 212 kbps/424 kbps passive 
mode specific error detection code (RE CRC) and length (LEN byte) shall be verified: 

In case the error detection code (RE CRC) and the LEN byte are correct and the received DATA_EIELD 
does not match with the applications available on the UICC, the UICC shall send a CLT frame without a 
DATA_EIELD to the CLE within 1 150 jis. 

In case the error detection code and the LEN byte are correct and the received DATA_EIELD matches 
the application available on the UICC, the UICC shall respond with an CLT frame containing the 
ISO/IEC 18092 [8] 212 kbps/424 kbps passive mode initiaHzation response frame ("POLLING 
RESPONSE", including the LEN and RE CRC field) encapsulated in the DATA_EIELD within 1 150 |is. 

In case an error with respect to ISO/IEC 18092 [8] 212 kbps/424 kbps passive mode is detected, the 
UICC shall send a CLT frame without a DATA_EIELD to the CLE within 1 150 |is. In this case, the 
CLE shall not transmit any data via RE. 

Figure 11.3 shows a CLT frame containing an ISO/IEC 18092 [8] 212 kbps/424 kbps passive mode based RE frame. 



CLT 



ADMIN 



18092 data 



SOF 



1 



1 







1 



Command + data 



RFCRC 



CRC16 



EOF 





18092 frame (212 kbps and 424 kbps) 




Preamble SYNC 


LEN CMDO CMD1 Byte Byte 1 ... Byte n 


E2 (CRC) 



Figure 11.3: ISO/IEC 18092 [8] 212 kbps/424 kbps passive mode data in a CLT frame (example) 
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In order to explain the byte arrangement of ISO/IEC 18092 [8] based frame data within a CLT LPDU, an example of an 
RF frame containing three data bytes and the RF CRC is shown in figure 1 1.4. 



Reception of ISO/IEC 18092 [8] 212/424 kbps passive mode based frame via RF: 

I- Byte 1-6 — I- Byte 7-8 — I Byte 9 1 Byte 10 1 Byte 11 



I bytes -►I 



MSB 



LSB MSB 



LSB MSB 



LSB 



Preamble 


SYNC 


Data-Byte 1 


Data-Byte 2 


Data- Byte 3 


RFCRC 



CLT LPDU with byte aligned DATA FIELD containing the received frame: 

I Bytel \ Byte 2 \ Byte 3 \ — 



b8 (MSB) 



Byte 4 



-2 bytes -►W 2 bytes -►! 



b1 (LSB) be 



b1 b8 



b1 be 



b1 






1 





1 


ADMIN 


1 1 1 1 1 1 1 
1 1 1 1 1 1 1 


1 1 1 1 1 1 1 
1 1 1 1 1 1 1 


1 1 1 1 1 1 1 
1 1 1 1 1 1 1 


RFCRC 


CRC16 



Data-Byte 1 



Data-Byte 2 



Data- Byte 3 



Figure 11.4: ISO/IEC 18092 [8] 212 kbps/424 kbps passive mode byte arrangement 

in a CLT frame (example) 

1 1 .5.3.3 CL_GOTO_INIT and CL_GOTO_HALT 

With these ADMIN_FIELD contents, the UICC shall inform the CLF about a necessary transition to initialization state 
with respect to the initialization state diagram on RF side. This may occur either in case of an error or if a dedicated 
transition command (e.g. "HLTA") was decoded by the UICC. 

In ISO/IEC 14443-3 [3] Type A, the CLF has to support two initialization branches, the corresponding actions are 
outlined in table 1 1.4. 

Table 11.4: Reasons and actions for CL GOTO INITandCL GOTO HALT 





The CLF was selected from IDLE state 
(via "READY/ACTIVE" states) 


The CLF was selected from HALT state 
(via "READY*/ACTIVE*" states) 


The UICC decodes an error 
^ send CL GOTO INIT 


Transition of the CLF to 
ISO/IEC 14443-3 [3] "IDLE" state 


Transition of the CLF to 
ISO/IEC 14443-3 [3] "HALT" state 


The UICC decodes a HLTA 

command 
^ send CL GOTO HALT 


Transition of the CLF to 
ISO/IEC 14443-3 [3] "HALT" state 


Transition of the CLF to 
IS0/IEC1 4443-3 [3] "HALT" state 



After the transition to ISO/IEC 14443-3 [3] "IDLE" or "HALT" state, the CLF shall process ISO/IEC 14443-3 [3] Type 
A RF protocol initialization, and proceed as described in clause 11.5.3.1. 

1 1 .6 CLT Protocol Rules 
11.6.1 Rules for the CLF 

The following rules apply for the CLF: 

• In order to open a new CLT session, the CLF shall send a CLT frame with ADMIN_FIELD set to 
CL_PROTO_INF(A) or CL_PROTO_INF(F) to the UICC, which closes also any former CLT session. 

• After having sent a CLT frame with ADMIN_FIELD set to CL_PROTO_INF(A), subsequently sent CLT 
frames within the CLT session shall be coded in Type A aligned manner. 
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• During a CLT session, on reception of a corrupted SWP frame or a CLT frame which contains an 
ADMIN_FIELD set to a value which is reserved for future use (see table 1 1.1) the CLF shall maintain the 
CLT LLC layer. 

11.6.2 Rules for the UICC 

The following rules apply for the UICC: 

• The UICC shall not send a CLT frame before having received a CLT frame with ADMIN_FIELD set to 
CL_PROTO_INF(A) or CL_PROTO_INF(F). 

• The UICC shall interpret a received CLT frame with ADMIN_FIELD set to CL_PROTO_INF(A) or 
CL_PROTO_INF(F)as condition to open a new CLT session and to close any former CLT session. 

• After having received a CLT frame with ADMIN_FIELD set to CL_PROTO_INF(A), subsequently sent CLT 
frames within the CLT session shall be coded in Type A aligned manner. 

• During a CLT session, the UICC shall ignore a corrupted SWP frame. 

• During a CLT session, the UICC shall ignore received CLT frames if at least one of the following conditions 
apply: 

the ADMIN_FIELD contains a value which is reserved for future use (see table 11.1). 

the length of the DATA_FIELD indicated for a Type A aligned CLT frame is invalid (see table 1 1 .2). 



12 Timing and performance 

12.1 SHDLC Data transmission mode 

12.1 .1 CLF processing delay when receiving data over an RF-link 

The CLF shall be able to send one or multiple Lframes over the SWP link to the UICC. These Lframes contain data 
from RF frames received from an external device such as PCD/Initiator or PICC/Target. The format and management of 
this data is out of the scope of the present document. The CLF shall ensure that the time from either: 

• receipt of the end of the RF frame to the end of the transmission (last bit of EOF) of the last Lframe containing 
data from the RF frame; or 

• in the case of chained RF frames and when the CLF receives the end of the next RF frame while it is still 
sending SWP data from the preceding RF frame,the end of transmission of the last Lframe conveying data 
from the preceding RF frame to the end of the transmission of the last Lframe conveying RF data of this 
subsequent RF frame; 

shall be less than T^-^p ^^^^^ receive ~ 500|is + (1 l|is per byte of RF data received which is to be sent over SWP). 

The formula above is valid only when the UICC acknowledges I-frames before the number of unacknowledged 
Lframes equals the sliding window size as defined in clause 10 and presumes error free communications over SWP. In 
the case where the UICC does not acknowledge I-frames before the number of unacknowledged I-frames equals the 
sliding window size then any resulting delay in the SWP transmission shall be added to T^-^p ^^^^^ receive- 

The CLF shall start the transmission of the RF acknowledgement, where required by the RF protocol, before the last bit 
of data related to it has been sent over SWP. 
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12.1.2 CLF processing delay when sending data over an RF-link 

When receiving data from the UICC in one or multiple I-frames the CLF shall remove the frame fragmentation and 
shall transmit the data conveyed by those I-frames over RF, fragmenting where necessary and shall ensure that the time 
between either: 

• the start of transmission (first bit of SOF) of the first I-frame to the start of the related RF frame; or 

• in the case of chained RF frames and the CLF has not received the acknowledge of the preceding RF frame at 
the time of the start of transmission of the first Lframe; 

• the end of the acknowledge of the previous RF frame to the start of the related RF frame; 

shall be less than T^^^p ^^^^^ transmit ~ 500|is + (1 l|is per byte of RF data to be sent in the related RF frame). 

The formula above is valid only when the UICC sends I-frames without a delay between each I-frame and presumes 
error free communications over SWP. If there is a delay between each I-frame due to the UICC, then the resulting delay 
in the SWP transmission shall be added to the value of T^^^p ^^^^^ transmit- 

The value of T^-^p ^^^^^ transmit presumes that the CLF does not generate S(WTX) and that the external PCD/Initiator 

acknowledges chained frames with no delay, any delay in acknowledging the RF frames shall be added to the value of 

T 

CLF,shdlc,transmif 

Figure 12.1: Void 

1 2.2 CLT data transmission mode for ISO/IEC 1 4443 Type A 

12.2.1 CLF processing delay when receiving data from the PCD 

The CLF receives RF data and sends data over SWP to the UICC. The processing delay by the CLF is defined as: 

• The time between receipt of the last bit of the RF data block and last data bit sent over SWP where: 

the last bit of the RF data block is the end of last pause transmitted by the PCD (see 
ISO/IEC 14443-3 [3]); and 

the last data bit sent over SWP is the end of the last bit of EOF on signal S 1 . 

This processing delay is designated as T^-^p receive- 

The CLF shall deliver the received RF data block as DATA_FIELD within exactly one CLT frame. In the case where 
the incoming RF data block exceeds the length limit of CLT LLC, an error on the RF side or wrong RF protocol type 
shall be assumed and proper error handling shall be executed (see note 1). 

NOTE 1 : If the length of the incoming RF data exceeds the maximum size of the DATA_FIELD, then the CLF may 
send to the UICC either a CLT frame with an incorrect CRC or an incorrect EOF or an empty CLT frame. 

NOTE 2: The CLF may start data transmission over SWP after having received a complete RF data block or may 
start data transmission over SWP while still receiving RF data (pipelining). 

12.2.2 CLF processing delay when sending data to the PCD 

The CLF receives data over SWP from the UICC and modulates it onto the RF. The processing delay by the CLF is 
defined as: 

• The time between the receipt of the first bit sent over SWP and the first bit sent to the PCD, where: 

the first bit sent over SWP is the start of the first bit of the SOF on signal S2; and 

the//r^^ bit sent to the PCD is the first modulation edge within the start bit (see ISO/IEC 14443-3 [3]). 
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In the case where no DATA_FIELD in the CLT frame is present (see clause 11.5.2), the processing delay by the CLF is 
defined as the time between the receipt of first bit sent over SWP from UICC to CLF and the time when the CLF shall 
be ready to receive the start bit of the next RF data block. 

This processing delay is designated as T^-^p transmit- 

The UICC shall deliver the RF data block as DATA_FIELD within exactly one CLT frame. The CLF shall deliver the 
received RF data within exactly one RF data block. 

Within a CLT session, on reception of a CLT frame with a DATA_FIELD present, the CLF may start sending data to 
the PCD after having received a complete CLT frame (non-pipelining) or may start sending data to the PCD while still 
receiving data over SWP (pipelining). In both cases, if the CRC is not correct, the CLF shall follow the rules given in 
clause 11.6.1 and in case of non-pipelining, the CLF shall not modulate the RF-field. 

1 2.2.3 Timing values for the CLF processing delay 

The total processing delay in the CLF shall not exceed T^-^p ^^j : 

"^CLF^elay " '^CLF,receive "^ '^CLF,transmit 
The maximum value for T^-^p ^^^ is calculated as: 

"^CLF delay = 210|is + (15|is per received byte of RF data) + (15 |is per sent byte of RF data). 

NOTE 1: In the formula ISO/IEC 14443-3 [3] start bits, parity bits and stop bits are not included. 




TCLF, receive 



SWP CLF -UICC 



RF CLF- PCD 



TCLF, transmit 



SWP UICC - CLF 



UICC Processing 
time 



NOTE: SWP CLF-UICC and SWP UICC-CLF represent the time taken to transmit the data over SWP and are 

included in the TcLF,receive and TcLF,transmit t'^es. 

Figure 12.2: CLF transmission timings 

The CLF and UICC should take care to ensure that processing delays do not comprise overall transactions times of 
commands and ensure that response PICC to PCD frame delay times can be achieved. 
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NOTE 2: In figure 12.2 TPICC represents a time equivalent to the total processing time of a Contactless card and is 
used to demonstrate the relationship between a card emulated by a CLF/UICC pair and a real card. 

Using the above diagram and the example of a typical ISO/IEC 14443 type A read command where the 
command from the PCD is 2 bytes long plus a CRC and the response is 16 bytes long plus a CRC then we 
would see: 

TCLF,delay = TCLF,receive + TCLF,transmit = 540 |is 

TPICC =540 |is plus the processing time of the UICC 

12.2.4 Timing value for the CLF processing delay (Request Guard Time) 

If the PCD sends a REQA or WUPA to the CLF during a CLT session, the CLF forwards the REQA or WUPA 
encapsulated in a CLT frame to the UICC (CLT PAYLOAD length 1 byte). The UICC may respond with a CLT frame 
with the ADMIN_FIELD CL_G0T0_INIT and no DATA_FIELD present. 

For this situation, the Request Guard Time (ISO/IEC 14443-3 [3]) has to be respected. The maximum value for 
TcLF,delay ^^• 

T(max)cLF,delay=190|IS 

NOTE: UICC and a CLF operating in CLT may be in the states ACTIVE or ACTIVE* (named as PICC states in 
ISO/IEC 14443-3 [3]). A REQA/WUPA sent by the PCD will force a transition to the PICC states IDLE 
or HALT (with no response from the CLF to the PCD). A subsequent REQA/WUPA will restart the 
collision resolution process. In some implementations, the PCD deliberately forces this error condition in 
order to exit the authenticated state of the PICC. 

1 2.3 CLT data transmission mode for IS0/IEC1 8092 
212kbps/424l<bps passive mode 

The CLF processing delay in this transmission mode is limited by the UICC processing time as defined in 
clause 11.5.3.2 and the Single Device Detection at 212kbps and 424kbps as defined in ISO/IEC 18092 [8]. 

NOTE: CompHance to the Single Device Detection at 212kbps and 424kbps as per ISO/IEC 18092 [8] is within 
the responsibility of the CLF, and is achieved by balancing its internal processing time and the SWP bit 
rates properly. 
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C 


Clarification of bit duration times - Removal of the 
295ns value. New optional minimum set to 590ns. 


7.0.0 


7.1.0 






SCP-070505 


007 




C 


Clarification of the SWP resume by the slave 
procedure. Removal of redundant figure. Text leading 
to interoperability issues changed. 


7.0.0 


7.1.0 






SCP-070505 
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c 


Clarification of the duration of the high and low states 
of the SI signal in order to have the intended 25/75 
ratio. 


7.0.0 


7.1.0 






SCP-070505 
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- 


F 


Clarification of the conditions of use of the RSET 
signal. 


7.0.0 


7.1.0 


2008-01 


SCP #35 


SCP-080023 


Oil 


- 


D 


Editorial corrections of SWP interface activation - 
figures in clause 6.2.3 modified 


7.0.0 


7.1.0 






SCP-080043 


013 


1 


F 


Clarification of l-frame reception process - Clarification 

of the use and processing of SREJ 

S-frame. 


7.0.0 


7.1.0 






SCP-080023 


014 




F 


Refinement of clausel 1 (CLT LLC definition) 
Clauses have been renumbered compared to CR in 
order not to break earlier references to the present 
document. 


7.0.0 


7.1.0 






SCP-080023 


015 




C 


Clarification of interface activation and LLC 
interworking - Several steps are clarified and a clause 
about LLC interworking is added 


7.0.0 


7.1.0 






SCP-080023 


016 


- 


C 


Clarification of the timing budget for the CLF. 
Additionally, the Request Guard Time is relaxed. 


7.0.0 


7.1.0 






SCP-080023 
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c 


Clarification of CLT data transmission mode. Removal 
of redundant text and correction of unclear and 
inconsistent text. 


7.0.0 


7.1.0 
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SCP #37 
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3 


F 


Clarification of identity check mechanism 
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F 


Clarification of the consequences of a link 
re-establishment 
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numbering 
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D 


Removal of informative Annex A which was thought to 
introduce misleading interpretations of clause 1 1 . 


7.1.0 


7.2.0 
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F 


Clarification on wakeup in order to avoid the possibility 
of a protocol deadlock 


7.1.0 
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F 


Clarification on contact vs. interface states and 
transitions. Removal of overlap and addition of clearer 
distinction between transitions and states. 


7.1.0 


7.2.0 
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- 


F 


Clarification of CLF processing delay 


7.1.0 


7.2.0 
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F 


Clarifications in clause 6.2.3.2 by adding some missing 
timing information and clarification of the layout. 


7.1.0 


7.2.0 
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- 


F 


Correction of the characteristic of SI-V(OL). Deletion of 
negative currents from the conditions. 


7.1.0 


7.2.0 
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- 


D 


Correction of note and grammatical errors 


7.1.0 


7.2.0 






SCP-080239 
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- 


D 


Correction of note 


7.1.0 


7.2.0 






SCP-080248 


028 


1 


C 


Clarification on bit stuffing 

Editor's note: incorrect CR number in SCP-080248. 

This should be 028 instead of 027. 
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